NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/363

Internet Message Format | 1996-08-06 | 5KB

Path: solon.com!not-for-mail
From: [e-mail]
Newsgroups: comp.std.c,comp.lang.c.moderated
Subject: Re: Integral promotion.
Followup-To: comp.std.c
Date: 23 Feb 1996 07:13:05 -0600
Organization: SoftQuad Inc., Toronto, Canada
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <4gkeh1$[e-mail]>
References: <4fstj7$[e-mail]> <4g28hr$[e-mail]> <4g54pv$[e-mail]> <4gfe6i$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

I wrote:
>>>> Thus even in ANSI C, if this function is called this way:
>>>>    extern short p, q, r, test(short,short);
>>>>    r = test(p,q);
>>>> the values from p and q are still converted from short to int and back
>>>> to short.  [but in the caller, where this is trivially optimizable-out]

And when challenged, justified this by citing:
>> ... 6.2.1.1/3.2.1.1, the passage which defines the integral
>> promotions.  It states that the promotions apply
>> #  in an expression wherever an int or unsigned int may be used.

This interpretation was objected to in the Referenced article by
Pete Becker ([e-mail]):

| there is a footnote to this section that says
|
|    The integral promotions are applied only as part of the usual
|    arithmetic conversions, to certain argument expressions, to the
|    operands of the unary +, -, and ~ operators, and to both operands
|    of the shift operators, AS SPECIFIED BY THEIR RESPECTIVE SECTIONS.
|    [emphasis added]
|
| That is, this section does not tell you what must be done every time
| you encounter something that could be promoted to int.  It tells you
| what the term "integral promotions" means when it is used in other
| sections...  In particular, it tells you what "integral promotions"
| means in the context of the "usual arithmetic conversions", which is
| where it is most often encountered.

And in article <4gfavt$[e-mail]>, in another branch of
the thread, by Norman Diamond ([e-mail]):

> 6.2/3.2 begins with the sentence:  "Several operators convert values
> from one type to another automatically." ...  The entire section is
> irrelevant to other contexts, such as those in which operators do not
> convert values automatically...

It is clear both from the footnote and the abundant references to
integral promotions throughout 6.3.*/3.3.* that Pete and Norman have
correctly interpreted the intent of the standard, so I was wrong to
that intent.  In my defense, I was fooled by the very explicit statement
that I cited in 6.2.1.1/3.2.1.1 -- and by similar language in K&R1, mem-
orized long ago -- into not looking for material that might contradict it.

And in fact, as to what the standard actually requires, I maintain that
I was right and Norman and Pete wrong.  But it doesn't matter anyway,
because both interpretations always yield the same result!

First off, footnotes are not part of the standard, so if they contradict
the text of the standard, they are supposed to be ignored.  Preferably,
in that case someone files a Defect Report and eventually the conflict
is resolved -- as Tanmoy Bhattacharya said in yet another branch of
the thread, moving the footnote into the main text would make sense.

Second, 6.2/3.2, in common with other sections of similar type, is best
read as a synopsis of the primary purpose of the sections that follow.
It is not stated as explicitly taking precedence over other material
such as 6.2.1.1/3.2.1.1; contrast this with the way that 7.1.7/4.1.6
does explicitly take precedence over the sections following it.

Also contrast 6.2.1.1/3.2.1.1, which defines the integral promotions
and states where they apply, with 6.2.1.5/3.2.1.5, which defines the
usual arithmetic conversions but does NOT state where they apply.
That is left to later sections in 6.3.*/3.3.*.

It is true that various sections in 6.3.*/3.3.* refer explicitly to
integral promotions occurring; these are redundant, since the values
in question would already have undergone the integral promotions
automatically (and a second integral promotion causes no change).
They do, as I said above, confirm that the intent was otherwise than
as I said previously.

Finally, there is the matter of sizeof.  If c is a char, and values
of type char are converted automatically to int, does it follow that
sizeof c should produce sizeof(int)?  No, it doesn't.  The reason
is that the operand of sizeof is defined as not being evaluated.
If it isn't evaluated, there's no value involved, and it's only
*values* ("rvalues" if you prefer) that undergo the integral promotions.

But none of this matters, because none of it ever causes an expression
to produce a different result.  Under the "as if" rule, if redundant
type conversions are required, they're not required to be *implemented*.

Followups directed to comp.std.c.
--
Mark Brader, [e-mail], SoftQuad Inc., Toronto
#define MSB(type)       (~(((unsigned type)-1)>>1))

My text in this article is in the public domain.